The annoying downside of this PR is that it will spam the server logs with errors in dev mode:

error TP1001 new Worker(./esbuild-worker.js relative, {"type": "module"}) is not statically analyse-able
   6 |         }
   7 |         super();
>  8 |         this.worker = new Worker(new URL("./esbuild-worker.js", import.meta.url), {
     |                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>  9 |             type: "module",
     | ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 10 |         });
     | ^^^^^^^^^^^
  11 |     }

These errors are caused by turbopack, which is unable to analyze two-arg version of new Worker. (source here, but I can't say I understand how exactly pattern-matching is implemented, and it's not documented anywhere).

The closest issue I could find in Next.js is this: vercel/next.js#72397; note that vercel/next.js#72397 (comment) specifically mentions the { type: "module" }, which causes errors.

The version without { type: "module" } would work if I compile the worker to esbuild-worker.cjs, and that's how I tried to do it previously, but .cjs files don't work on Vercel (they're served with the wrong content-type).

If there's no .cjs extension, and no { type: "module" }, then turbopack, and I think webpack too, would still interpret the worker URL to be a module (probably because squiggle-lang is an ESM package, configured with "type": "module" in package.json), and inject "import" statements in dev, which then breaks the worker when the browser tries to run it, because the worker constructor didn't ask for it be to be a module.

There might be some combination of esbuild parameters that would solve it, but I couldn't find it.

To reiterate, these errors don't prevent next dev --turbo from functioning. The only issue that I can find is console errors, and I hope that those will be fixed on turbopack side eventually.